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(54) Gaming software authentication 

(57) A method of preparing memory contents of a 
gaming machine for subsequent authentication and a 
method of authenticating the prepared memory con- 
tents are disclosed. A first memory stores a game data 
set and a first authentication code generated from the 
game data set. The game data set includes game data 
files and second authentication codes generated from 
the respective data files. A second memory stores an 
authentication program for authenticating the first mem- 
ory's contents, as well as a third authentication code 
generated from the second memory's contents. To au- 
thenticate the memory contents, the second memory's 
contents are first authenticated and, if deemed authen- 
tic, the game data set as a whole and each data file in 
the first memory are authenticated. The authentication 
process involves generating fresh authentication codes 
using the authentication program and comparing the 
fresh codes with appropriate ones of the stored authen- 
tication codes. 
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Description 

FIELD OF THE INVENTION 

[0001] The present Invention relates generally to 
gaming machines and, more particularly, to software au- 
thentication in a gaming machine. 

BACKGROUND OF THE INVENTION 

[0002] As a regulatory requirement in virtually all ju- 
risdictions that allow gaming, it is necessary to have a 
technique to authenticate that the software installed in 
a gaming machine is tested and approved. In the past, 
gaming manufacturers have generally used EPROM- 
based hardware platforms to store program code. As a 
result, a number of software authentication techniques 
have been accepted as standards throughout the gam- 
ing industry. Depending upon the preferences of the lo- 
cal regulatory agency, these techniques generally in- 
clude either a Kobetron signature or a hash function 
based on the data stored in the EPROM device. 
[0003] Authentication of software programs basically 
occurs using two different methods in the field, again 
determined by the local regulatory agency. In one meth- 
od, each EPROM is authenticated by a gaming agent 
prior to being installed in a gaming machine that is to be 
brought up for play. The EPROMs may be shipped di- 
rectly to the gaming agency for authentication prior to 
the install date of the machine, or may be authenticated 
on the casino floor as the software is being installed in 
the machine. In another method, authentication is con- 
ducted on a spot-check basis. A gaming agent periodi- 
cally visits a casino and picks machines selectively or 
at random to remove the software components for au- 
thentication. 

[0004] Due to advances in technology that have been 
made in recent years, EPROM -based hardware plat- 
forms are becoming obsolete and newer technologies 
are being Introduced into the gaming Industry. These ad- 
vanced technologies utilize storage devices that have 
been classified as "high capacity storage devices." High 
capacity storage devices may, for example, include 
CD-ROMs, hard disk drives, and flash devices. Thus far, 
there is no industry standard method for authenticating 
these types of devices. 

SUMMARY OF THE INVENTION 

[0005] The present invention provides a method of 
preparing memory contents of a gaming machine for 
subsequent authentication and a method of authenticat- 
ing the prepared memory contents. A first memory 
stores a game data set and a first authentication code 
generated from the game data set. The game data set 
includes game data files and second authentication 
codes generated from the respective data files. A sec- 
ond memory stores an authentication program for au- 



thenticating the first memory's contents, as well as a 
third authentication code generated from the second 
memory's contents. The first memory is preferably a 
high capacity storage device, while the second memory 

5 is preferably a boot read-only memory. To authenticate 
the memory contents, the second memory's contents 
are first authenticated and, if deemed authentic, the 
game data set as a whole and each data file in the first 
memory are authenticated. The authentication process 

10 involves generating fresh authentication codes using 
the authentication program and comparing the fresh 
codes with appropriate ones of the stored authentication 
codes. 

13 BRIEF DESCRIPTION OF THE DRAWINGS 

[0006] The foregoing and other advantages of the in- 
vention will become apparent upon reading the following 
detailed description and upon reference to the drawings. 

FIG. 1 is an Isometric view of a gaming machine 
operable to conduct a wagering game. 
FIG. 2 Is a block diagram of computer-readable 
storage contained in the gaming machine. 
FIG. 3 is a flow diagram of a method of generating 
digital signatures from contents of the computer- 
readable storage for subsequent authentication. 
FIG. 4 is a flow diagram of a method of authenticat- 
ing the digital signatures. 

FIGS. 5a and 5b are a flow diagram of a multi-stage 
authentication procedure executed external to the 
gaming machine and then internal to the gaming 
machine during a system boot process. 
FIG. 6 is a flow diagram of a continuous run-time 
authentication procedure executed by the gaming 
machine after a main software application is 
launched from system RAM. 

[0007] While the invention is susceptible to various 
modifications and alternative forms, specific embodi- 
ments have been shown by way of example in the draw- 
ings and will be described in detail herein. It should be 
understood, however, that the invention is not intended 
to be limited to the particular forms disclosed. Rather, 
the invention is to cover all modifications, equivalents, 
and alternatives falling within the spirit and scope of the 
invention as defined by the appended claims. 

DESCRIPTION OF ILLUSTRATIVE EMBODIMENTS 

[0008] Turning now to the drawings and referring ini- 
tially to FIG. 1 , a gaming machine 10 is operable to con- 
duct a wagering game such as mechanical or video 
slots, poker, keno, bingo, or blackjack. If based in video, 
the gaming machine 1 0 includes a video display 1 2 such 
as a cathode ray tube (CRT), liquid crystal display 
(LCD), plasma, or other type of video display known in 
the art. A touch screen preferably overlies the display 
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12. In the Illustrated embodiment, the gaming machine 
10 is an "upright" version In which the display 12 is ori- 
ented vertically relative to a player. Alternatively, the 
gaming machine may be a "slant-top" version in which 
the display 12 is slanted at about a thirty-degree angle 
toward the player. 

[0009] The gaming machine 1 0 includes a plurality of 
possible credit receiving mechanisms 14 for receiving 
credits to be used for placing wagers in the game. The 
credit receiving mechanisms 14 may, for example, in- 
clude a coin acceptor, a bill acceptor, a ticket reader, 
and a card reader. The bill acceptor and the ticket reader 
may be combined into a single unit. The card reader 
may, for example, accept magnetic cards and smart 
(chip) cards coded with money or designating an ac- 
count containing money. 

[001 0] The gaming machine 1 0 includes a user inter- 
face comprising a plurality of push-buttons 16, the 
above-noted touch screen, and other possible devices. 
The plurality of push-buttons 16 may, for example, in- 
clude one or more "bet" buttons for wagering, a "play" 
button for commencing play, a "collect" button for cash- 
ing out, a "help" button for viewing a help screen, a "pay 
table" button for viewing the pay table(s), and a "call at- 
tendant" button for calling an attendant. Additional 
game-specific buttons may be provided to facilitate play 
of the specific game executed on the machine. The 
touch screen may define touch keys for implementing 
many of the same functions as the push-buttons. Other 
possible user interface devices include a keyboard and 
a pointing device such as a mouse or trackball. 
[0011] A central processing unit (CPU) controls oper- 
ation of the gaming machine 10. In response to receiving 
a wager and a command to initiate play, the CPU ran- 
domly selects a game outcome from a plurality of pos- 
sible outcomes and causes the display 12 to depict in- 
dicia representative of the selected game outcome. In 
the case of slots, for example, mechanical or simulated 
slot reels are rotated and stopped to place symbols on 
the reels in visual association with one or more pay lines. 
If the selected outcome is one of the winning outcomes 
defined by a pay table, the CPU awards the player with 
a number of credits associated with the winning out- 
come. 

[001 2] The CPU includes a microprocessor and com- 
puter-readable storage. Referring to FIG. 2, in a pre- 
ferred embodiment, the computer-readable storage in- 
cludes a boot memory 20, a high capacity storage mem- 
ory 22, and a serial read-write memory 24. The boot 
memory 20 is preferably a read-only memory such as a 
one megabit EPROM. The high capacity storage mem- 
ory 22 is preferably a compact flash card. The serial 
memory 24 is preferably an EEPROM such as a 512 
byte SPI EEPROM Depending upon the preferences of 
the local regulatory agency, all three memories may be 
authenticated both outside of the CPU and then when 
installed in the CPU at power up. The diagram in FIG. 
2 displays the contents stored in each of the memories 



and authenticated prior to use in the gaming machine. 
[0013] The boot memory 20 stores boot code, an au- 
thentication program, a RAM loader, a decompression 
utility 1 20, and a digital signature 30. The authentication 
5 program includes a hash function 42, a digital signature 
algorithm (DSA) verify operation 44a, and a public key 
46a. The hash function 42 may, for example, be an SHA- 
1 hash algorithm that reduces a data set to a unique 160 
bit message digest. The digital signature 30 is generat- 
io ed from the boot memory's contents as a whole. 

[0014] The high capacity storage memory 22 stores 
game and operating system executable program files, 
sound operating system files, sound bank files, graphics 
files, a manifest file, and a digital signature 32. The 
15 above files, taken together, constitute a "game data set" 
as that term is used herein, and the various files consti- 
tute "data files" as that term is used herein. Thus, the 
game data set includes a plurality of data files. For each 
data file on the high capacity storage memory 22, the 
manifest file contains a file name, a file type, a load ad- 
dress, and a digital signature 34. The digital signature 
32 is generated from the game data set as a whole, while 
each digital signature 34 is generated from the associ- 
ated data file listed in the manifest file. 
[0015] The serial memory 24 stores information spe- 
cific to the jurisdiction where the CPU is to be installed. 
This information may, for example, include a lottery ter- 
minal identification (ID), a part number, a jurisdiction ID, 
a jurisdiction name, jurisdiction bit code options, juris- 
diction max bet, jurisdiction max win, and a digital sig- 
nature 36. The digital signature 36 is generated from the 
serial memory's contents as a whole. 
[0016] The digital signatures 30, 32, 34, and 36 in the 
various memories are preferably generated and authen- 
ticated using the Digital Signature Standard as adopted 
by the U .S . Department of Commerce / National Institute 
of Standards and Technology and published in FIPS 
PUB 186-2 on January 27, 2000 
[0017] FIG. 3 illustrates a method of generating the 
digital signatures 30, 32, 34, and 36 for subsequent au- 
thentication. The method is performed outside of the 
gaming machine during an engineering release proc- 
ess. Specifically, each digital signature is generated 
from associated memory contents 40 by reducing the 
contents 40 to a message digest 46 using the hash func- 
tion 42 and then inputting the message digest 46 and a 
private key 46b into a DSA generation operation 44b 
[001 8] The associated contents 40 from which each 
digital signature is generated varies as described above 
in connection with FIG. 2. Specifically, the digital signa- 
ture 30 is generated from the contents of the boot mem- 
ory 20 as a whole. The digital signature 32 is generated 
from the game data set in the high capacity storage 
memory 22 as a whole, while the digital signatures 34 
are generated from the respective data files (except the 
manifest file) making up the game data set. Some of the 
data files, such as the sound and graphics files, may be 
compressed. A compressed data file(s) may itself in- 
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elude a plurality of uncompressed data files. A digital 
signature 34 may be generated from the compressed 
data file, and either a digital signature 34 or a message 
digest 48 may be generated from the data file prior to 
compression (i.e., the uncompressed data file). The dig- 
ital signature 34 or message digest 48 generated from 
an uncompressed data file may be appended to the 
compressed data file. The digital signature 36 is gener- 
ated from the contents of the serial memory 24 as a 
whole. The hash function 42 used in the signature gen- 
eration method is the same as the hash function 42 
stored in the boot memory 20. The aforementioned pub- 
lic key 46a stored in the boot memory 20 and the private 
key 46b form an associated pair in accordance with the 
Digital Signature Standard. The same public key / pri- 
vate key pair 46a-b is preferably used to generate and 
authenticate all digital signatures. Alternatively, different 
public key / private key pairs may be used to generate 
and authenticate one or more of the digital signatures. 
[0019] FIG. 4 illustrates a method of authenticating 
the digital signatures 30, 32, 34, and 36 already stored 
in the memories. The timing of this method is described 
below in connection with FIG. 5 and depends upon the 
digital signature being authenticated The method em- 
ploys the boot memory's authentication program, which 
includes the hash function 42, the DSA verify operation 
44a, and the public key 46a. In the authentication meth- 
od, a fresh digital signature 50 is generated from previ- 
ously signed memory contents 40 by reducing the con- 
tents 40 to a message digest 48 using the hash function 
42 and then inputting the message digest 48 and the 
public key 46a into the DSA verify operation 44a. The 
message digest 48 is also stored in a non-volatile ran- 
dom access memory (RAM) for later use during contin- 
uous run-time authentication. The fresh digital signature 
50 is then mathematically complemented at step 52 to 
yield a complement 54 of the fresh signature 50. The 
signature complement 54 is summed with the stored 
digital signature (i.e., digital signature 30, 32, 34, or 36) 
generated from the same memory contents 40. If the 
mathematic sum 56 is zero (i.e., the fresh signature 50 
matches the stored signature), authentication is 
deemed a success at step 58. If, however, the mathe- 
matic sum 56 is not zero, authentication is deemed a 
failure at step 60. 

[0020] Referring to FIGS. 5a and 5b, the procedure 
for authenticating the contents of the memories 20, 22, 
and 24 is implemented in the following distinct stages: 
external component authentication, internal boot com- 
ponent authentication, file authentication and loading, 
and continuous run-time authentication (see FIG. 6). 
This authentication procedure guarantees the integrity 
and security of the CPU software. A failure detected in 
any one of the stages is considered a critical failure that 
must be corrected prior to any further play of the gaming 
machine. The machine displays the critical failure, if de- 
tected, at step 96. 

[0021 ] External component authentication verifies the 



contents of the memories prior to placement in the gam- 
ing machine. Alternatively, If permitted by the local gam- 
ing agency, the memory contents may be verified using 
a dedicated serial port after the memories have been 
5 installed in the CPU. External component authentication 
of the boot memory 20 may be accomplished using in- 
dustry standard techniques, such as a Kobetron MT- 
2000 signature or a hash algorithm for generating a 
unique signature (step 70). External component authen- 
10 tication of the high capacity storage memory 22 may be 
accomplished using tools commercially available from 
such companies as Kobetron Inc. of Navarre, Florida, 
Gaming Laboratories International Inc. (GLI) of Toms 
River, New Jersey, and Dataman Programmer Ltd. of 
15 Orange City, Florida (step 72). External component au- 
thentication of the serial memory 24, which requires a 
serial communications interface to read from and write 
to the memory, may be accomplished using tools com- 
mercially available from one or more of the aforemen- 
tioned companies (step 74). 

[0022] Internal boot component authentication occurs 
immediately following power up of the machine and en- 
tails authentication of the contents of each installed 
memory as a whole and does not look at individual files 
stored in the memory. Authentication of individual files 
occurs during a later stage. After powering up (booting) 
the machine at step 76, a Power On Self Test (POST) 
is immediately initiated at step 78 to initialize the CPU 
hardware and run a few basic tests to verify that the 
hardware is functioning correctly. After the POST, the 
three memories are authenticated as a whole using the 
method in FIG. 4 and in the following sequence: (1) au- 
thenticate digital signature 30 of boot memory 20 at step 
80, (2) authenticate digital signature 36 of serial memory 
24 at step 82, and (3) authenticate digital signature 32 
of high capacity storage memory 22 at step 86. The boot 
memory 20 is authenticated first because the other two 
memories rely upon the contents of the boot memory 20 
to complete their own authentication processes. Prior to 
authenticating the high capacity storage memory 22 at 
step 86, that memory's drivers and file system are ini- 
tialized at step 84. If all three memories have been de- 
termined to be both present and authentic, the authen- 
tication procedure proceeds to the next stage - file au- 
thentication and loading. 

[0023] File authentication and loading sequentially 
authenticates the executable data files (except for the 
manifest file) stored in the high capacity storage mem- 
ory 22 and loads each authenticated data file into the 
CPU component (e.g., system RAM) where the data file 
will reside and execute from during normal machine op- 
eration. The data files are loaded and processed in the 
order listed in the manifest file stored in the high capacity 
storage device 22. The manifest file itself is not loaded 
into the system, but rather is used during the system 
boot process to guide the file loading process. The order 
in which the data files are loaded does not have an effect 
on system operation. 
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[0024] The digital signature 34 of a data file in the high 
capacity storage memory 22 is authenticated at step 88 
using the method in FIG. 4. If the data file is compressed, 
the digital signature 34 generated from the compressed 
data file is authenticated at step 88. If the digital signa- 
ture 34 is authenticated, a check is made at step 89 as 
to whether or not the data file is compressed. If the data 
file is not compressed, the data file is loaded to an as- 
sociated CPU component at step 90. The associated 
CPU component is identified in the manifest file. If, how- 
ever, the data file is compressed, the compressed data 
file is decompressed using the decompression utility 
120 stored in the boot memory 20 at step 91. The de- 
compressed data file may be authenticated prior to be- 
ing loaded to the associated CPU component at step 
93. The message digest 48 calculated during such au- 
thentication is stored in the n on -volatile random access 
memory (RAM) for later use during continuous run-time 
authentication. A check is then made at step 92 as to 
whether or not the loaded data file was the last file listed 
in the manifest file. If not, the file authentication and 
loading steps are repeated for the next data file listed in 
the manifest file. After authenticating and loading the 
last file and performing a RAM clear check (not shown), 
the main software application is launched from system 
RAM at step 94 to complete the system boot process. 
The authentication procedure then proceeds to the final 
stage - continuous run-time authentication. 
[0025] FIG. 6 illustrates a basic method of continuous 
run -time authentication as it will take place following the 
completion of the system boot process. There are two 
main cycles of events that occur during continuous run- 
time authentication. The first cycle repeatedly verifies 
the presence of the high capacity storage memory 22 in 
the CPU board, and calculates and verifies the message 
digest 48 (see FIG. 4) for the memory 22 as a whole at 
steps 100, 102, and 104. The high capacity storage 
memory 22 is accessed at short time intervals such as 
every 15 milliseconds. Any unsuccessful read of the 
high capacity storage memory 22 at step 1 00 or any un- 
successful authentication at step 104 halts the machine 
and causes it to display a critical error at step 96. The 
continuous run-time authentication of the high capacity 
storage memory 22 is limited to the memory as a whole 
and does not look at individual files stored on the mem- 
ory. 

[0026] The second cycle involves repetitive authenti- 
cation of the serial memory 24 at step 106, the boot 
memory 20 at step 1 08, and the files that are executing 
from system RAM at steps 110 and 112. All authentica- 
tions are preferably accomplished using the message 
digest 48 of the corresponding memory or file, instead 
of the DSA verify operation in FIG. 4. Message digests 
48 of the various memories and files (including the de- 
compressed data files) were previously stored in non- 
volatile RAM, and it is against these stored message di- 
gests 48 that newly calculated message digests are 
compared. The DSA verify operation is not necessary 



at this point because the memories and files were prov- 
en to be authentic during the system boot process. The 
purpose of continuous run-time authentication is to en- 
sure that the information that was loaded to system RAM 
5 during the boot process has not been altered and that 
the memories have not been changed. A message di- 
gest 48 is sufficient for this purpose, ft should be under- 
stood, however, that the DSA verify operation may in- 
stead be performed during this second cycle of contin- 
10 uous run-time authentication. 

[0027] Following the successful authentication of all 
files in system RAM, the non-volatile RAM is verified us- 
ing a standard "CRC" or other similar check at step 114. 
Main and auxiliary copies of the non-volatile RAM are 

is also compared to each other at step 1 14 to ensure the 
integrity of the non-volatile RAM. In accordance with 
step 116, all of the above functions of the second cycle 
continue for as long as the machine is powered on. If 
the machine is powered off, the authentication proce- 
ss dure will start again at the boot component authentica- 
tion stage in FIG. 5 when the machine is powered up. 
[0028] While the present invention has been de- 
scribed with reference to one or more particular embod- 
iments, those skilled in the art will recognize that many 

25 changes may be made thereto without departing from 
the spirit and scope of the present invention. 
[0029] For example, as noted above, numerous tech- 
niques may be used to prepare and authenticate a com- 
pressed data set The compressed data set may include 

30 one or more files in the high capacity storage memory 
22. In the illustrated embodiment, to prepare a com- 
pressed data set for subsequent authentication, the per- 
formed steps include compressing an uncompressed 
game data set; generating a first authentication code 

35 from the compressed data set; and storing the com- 
pressed data set and the first authentication code in the 
high capacity storage memory 22. The compressed da- 
ta set may include sound files, graphics files, and even 
executable game code. The first authentication code 

40 may be a message digest 48 or a digital signature 34 
(see FtG. 3). The manifest file In the high capacity stor- 
age memory 22 lists the compressed data set and its 
associated first authentication code. 
[0030] Prior to compressing an uncompressed data 

*3 set, a second authentication code may be generated 
from the uncompressed data set and appended to the 
compressed data set. The second authentication code 
may be a message digest 48 or a digital signature 34 
(see FIG. 3). The manifest file in the high capacity stor- 

30 age memory 22 lists the compressed data set and the 
first and second authentication codes generated from 
the respective compressed and uncompressed data 
sets. 

[0031] To authenticate a data set that has been pre- 
55 pared in the above manner, the performed steps include 
authenticating the compressed data set; decompress- 
ing the compressed data set using a decompression util- 
ity stored in the boot memory; and authenticating the 
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decompressed data set. Both the compressed data set 
and the decompressed data set may be authenticated 
during the file authentication and loading stage shown 
in FIG. 5b by generating fresh authentication codes that 
are compared to the respective stored first and second 
authentication codes. If a stored authentication code is 
a message digest 48 (see FIG. 3), then the fresh au- 
thentication code against which It is compared is also a 
message digest (see FIG. 4). If, however, the stored au- 
thentication code is a digital signature 34 (see FIG. 3), 
then the fresh authentication code against which it is 
compared is a digital signature 50 (see FIG. 4). After the 
decompressed data set is loaded into its associated 
CPU component (e.g., system RAM), the decom- 
pressed data set may again be authenticated during 
continuous run-time authentication shown in FIG. 6 by 
generating a fresh authentication code that is compared 
to the stored second authentication code of the same 
type (i.e., message digest or digital signature). 
[0032] The compressed data set may include a plu- 
rality of uncompressed data files. When preparing the 
compressed data set for subsequent authentication, a 
respective authentication code may be generated for 
each of these uncompressed files and stored in the 
manifest file These authentication codes are then later 
authenticated after decompressing the compressed da- 
ta set 

[0033] Depending upon the level of authentication 
needed to comply with a regulatory gaming body, the 
authentication method may be modified to authenticate 
the compressed data set only prior to decompression or 
only after decompression. 

[0034] Each of these embodiments and obvious var- 
iations thereof is contemplated as falling within the spirit 
and scope of the claimed invention, which is set forth in 
the following claims: 



Claims 

1 . A method of preparing memory contents of a gam- 
ing machine for subsequent authentication, com- 
prising: 

generating first authentication codes from re- 
spective game data files; 
storing the first authentication codes and the re- 
spective data files in one or more first memo- 
ries, the first authentication codes and the re- 
spective data files being included in a game da- 
ta set; 

generating a second authentication code from 
the game data set; and 

storing the game data set and the second au- 
thentication code in the one or more first mem- 
ories. 

2. The method of claim 1 , wherein the step of gener- 



ating first authentication codes includes reducing 
each data file to a message digest and then input- 
ting the message digest and a private key into a dig- 
ital signature algorithm generation operation. 

5 

3. The method of claim 1 , wherein the step of gener- 
ating a second authentication code includes reduc- 
ing the game data set to a message digest and then 
inputting the message digest and a private key into 

10 a digital signature algorithm generation operation. 

4. The method of claim 1 , wherein the one or more first 
memories include a high capacity storage device. 

15 5. The method of claim 1 , wherein the step of gener- 
ating first authentication codes includes reducing 
each game data file to a respective first message 
digest using a hash function and then inputting the 
first message digest and a private key into a digital 
20 signature algorithm generation operation, wherein 
the step of generating a second authentication code 
includes reducing the game data set to a second 
message digest using the hash function and then 
inputting the second message digest and the pri- 
23 vate key into the digital signature algorithm gener- 
ation operation. 

6. The method of claim 5, further including storing the 
hash function in a second memory. 

30 

7. The method of daim 6, further including storing a 
digital signature algorithm verify operation and a 
public key in the second memory. 

35 8. The method of claim 7, wherein the second memory 
is a read-only memory. 

9. The method of claim 8, further including generating 
a third authentication code from contents of the sec- 
40 ond memory, the contents including the hash func- 
tion, the public key, and the digital signature algo- 
rithm verify operation, and storing the contents and 
the third authentication code in the second memory. 

45 10. The method of claim 1 , further including generating 
a third authentication code from contents of a sec- 
ond memory, the contents including an authentica- 
tion program for authenticating the first memory, 
and storing the contents and the third authentication 
50 code in the second memory. 

11. The method of claim 10, wherein the second mem- 
ory is a read-only memory. 

55 12. The method of claim 1 0, wherein the second mem- 
ory is a boot memory. 

13. A method of authenticating memory contents of a 
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gaming machine, comprising: 

storing, in one or more memories, a game data 
set and a first authentication code generated 
from the game data set, the game data set in- 
cluding data files and second authentication 
codes generated from the respective data files; 
storing an authentication program in the one or 
more memories; 

generating a third authentication code from the 
game data set using the authentication pro- 
gram, and 

determining the game data set is authentic if 
the third authentication code matches the first 
authentication code. 

14. The method of daim 1 3, wherein the game data set 
and the first authentication code are stored in a high 
capacity storage device, and the authentication pro- 
gram is stored in a read-only memory. 

15. The method of claim 13, further including generat- 
ing fourth authentication codes from the respective 
data files using the authentication program, and de- 
termining the data files are authentic if the fourth 
authentication codes match the respective second 
authentication codes. 

16. The method of claim 13, wherein the first authenti- 
cation code is generated from the game data set by 
reducing the game data set to a first message digest 
using a hash function and then inputting the first 
message digest and a private key into a digital sig- 
nature algorithm generation operation, and wherein 
the step of generating a third authentication code 
includes reducing the game data set to a second 
message digest using the hash function and then 
inputting the second message digest and a public 
key into a digital signature algorithm verify opera- 
tion. 

17. The method of claim 1 6, wherein the step of storing 
an authentication program in the one or more mem- 
ories includes storing the hash function, the public 
key, and the digital signature algorithm verify oper- 
ation in the one or more memories. 

18. The method of claim 1 3, wherein the game data set 
and the first authentication code are stored in a first 
memory, and the authentication program is stored 
in a second memory, and further including authen- 
ticating contents of the second memory prior to the 
step of generating a third authentication code. 

19. The method of claim 18, further including storing, in 
the second memory, a fourth authentication code 
generated from the contents of the second memory, 
and wherein the step of authenticating contents of 



the second memory includes generating a fifth au- 
thentication code from the contents using the au- 
thentication program and determining the contents 
are authentic if the fifth authentication code match- 
5 es the fourth authentication code. 

20. Computer- readable storage for a gaming machine, 
comprising a first memory storing a game data set 
and a first authentication code generated from the 

10 game data set, the game data set including a plu- 
rality of game data files and plurality of second au- 
thentication codes, the second authentication 
codes being generated from the respective data 
files. 

15 

21. The storage of claim 20, wherein the first memory 
is a high capacity storage device. 

22. The storage of claim 20, wherein the game data set 
20 includes a manifest file listing the data files and their 

respective second authentication codes in an order 
in which the data files will be authenticated. 

23. The storage of claim 20, further including a second 
25 memory storing contents, the contents including an 

authentication program for authenticating the first 
memory. 

24. The storage of claim 23, wherein the second mem- 
30 ory is a read-only memory. 

25. The storage of claim 23, wherein the second mem- 
ory is a boot memory. 

35 26. The storage of claim 23, wherein the authentication 
program includes a hash function, a digital signa- 
ture algorithm verify operation, and a public key. 

27. The storage of claim 23, wherein the second mem- 
40 ory also stores a third authentication code generat- 
ed from the contents. 

28. A method of preparing memory contents of a gam- 
ing machine for subsequent authentication, com- 

45 prising: 

compressing an uncompressed game data set; 
generating an authentication code from the 
compressed data set; and 
so storing the compressed data set and the au- 

thentication code in one or more memories 

29. The method of claim 28, wherein the data set is se- 
lected from a group consisting of sound files and 

55 graphics files. 

30. The method of claim 28, wherein the step of gener- 
ating an authentication code includes reducing the 
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compressed data set to a message digest and then 
Inputting the message digest and a private key into 
a digital signature algorithm generation operation. 

31. The method of claim 28, wherein the step of gener- 
ating an authentication code Includes reducing the 
compressed data set to a message digest. 

32. The method of claim 28, wherein the step of storing 
the compressed data set and the authentication 
code includes storing the compressed data set and 
the authentication code in the same memory. 

33. The method of claim 33, wherein the same memory 
is a high capacity storage memory. 

34. The method of claim 28, further including generat- 
ing a second authentication code from the uncom- 
pressed data set, and storing the second authenti- 
cation code in the one or more memories. 

35. The method of claim 34, wherein the step of gener- 
ating a second authentication code includes reduc- 
ing the uncompressed data set to a message digest 
and then inputting the message digest and a private 
key into a digital signature algorithm generation op- 
eration. 

36. The method of claim 34, wherein the step of gener- 
ating a second authentication code includes reduc- 
ing the uncompressed data set to a message di- 
gest. 

37. The method of claim 34, wherein the step of storing 
the second authentication code includes appending 
the second authentication code to the compressed 
data set. 

38. The method of claim 28, wherein the compressed 
data set includes a plurality of uncompressed data 
files. 

39. A method of authenticating memory contents of a 
gaming machine, comprising: 

authenticating a compressed data set; 
decompressing the compressed data set; and 
authenticating the decompressed data set. 

40. The method of claim 39, further including storing, in 
one or more memories, the compressed data set 
and a first authentication code generated from the 
compressed data set. 

41 . The method of claim 40, wherein the step of authen- 
ticating the compressed data set includes generat- 
ing a second authentication code.from the com- 
pressed data set and determining the compressed 



data set is authentic if the second authentication 
code matches the first authentication code. 

42. The method of claim 41 , wherein the first and sec- 
5 ond authentication codes are message digests. 

43. The method of claim 41 , wherein the first and sec- 
ond authentication codes are digital signatures. 

10 44. The method of claim 39, wherein the step of decom- 
pressing the compressed data set is accomplished 
using a decompression utility stored in a read-only 
memory. 

f5 45. The method of claim 39, further including storing, in 
one or more memories, a first authentication code 
generated from the data set prior to being com- 
pressed. 

20 46. The method of claim 45, wherein the step of authen- 
ticating the decompressed data set includes gener- 
ating a second authentication code from the decom- 
pressed data set and determining the decom- 
pressed data set is authentic if the second authen- 

23 tication code matches the first authentication code. 

47. The method of claim 46, wherein the first and sec- 
ond authentication codes are message digests. 

30 48. The method of claim 46, wherein the first and sec- 
ond authentication codes are digital signatures. 

49. The method of claim 39, further including loading 
the decompressed data set into a CPU component. 

35 

50. The method of claim 49, wherein the step of authen- 
ticating the decompressed data set is performed 
both before and after the step of loading the decom- 
pressed data set into a CPU component 

40 

51. The method of claim 39, wherein the compressed 
data set includes a plurality of uncompressed data 
files, and further including authenticating each of 
the uncompressed data files after the step of de- 

45 compressing the compressed data set. 
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